In a client-server deployment, clients may be authenticated using physical tokens, such as smart cards, USB authentication tokens or the like. These physical tokens may be used in connection with strong authentication protocols to authenticate clients to one or more servers.
In one deployment model, one or more intermediate gateways may be arranged between the clients and the servers. For a number of reasons, such as load balancing, application sharing, or the like, a given deployment may include a plurality of end servers. If a client wishes to access one of the end servers, for example, the client first authenticates to one of the intermediate gateways. In this manner, the intermediate gateway provides a front-end for one or more back-end servers.
Once the client has authenticated to the intermediate gateway, different scenarios are possible. First, if the deployment model uses trust, the other entities in the model simply trust the intermediate gateway, without re-authenticating the client. Under a trust-based model, once the client has authenticated to the gateway, the client may effectively have access to each entity in the deployment. However, if the gateway is compromised by an intruder, any client who has delegated rights to the gateway may be impersonated by the intruder, and any server using the gateway as a front end may be attacked. Therefore, the trust-based model reduces the security of the overall system, and poses risk to all clients and servers in the system.
One approach to mitigating the risk of a trust-based model is to employ a delegation-based model. In a delegation-based model, after the client authenticates to the intermediate gateway, the client delegates its credentials to the gateway. Having received the client's credentials, the gateway uses these credentials to authenticate on the client's behalf to one or more additional entities, such as gateways or end servers. These other entities then judge the client's credentials for themselves, and determine independently whether to authenticate the client. Put differently, in the delegation model, the gateway is legitimately “impersonating” the client to one or more other entities. In contrast, under the trust model, these other entities simply trust the gateway that first authenticated the client.
It may be desired to combine the security of strong authentication with the benefits of the delegation model. The delegation model entails using credentials that are delegable or reusable. However, strong authentication protocols and related tokens are, by definition, not reusable or delegable to other entities. Therefore, previous approaches have not been able to provide the security of strong authentication with the flexibility of explicit delegation.